chore(deps): bump the vendored tinymemory pin past #76/#77 - #5657

…nyhumansai#77

The pin sat at 38a34d2, which predates every fix the memory-stack audit
produced upstream. Provably in the compiled product, that meant each keyed
remote get was still a whole-account enumeration, hosted errors all collapsed
to one opaque variant, and the Supermemory re-store blocker was live.

This moves the submodule to tinymemory main (1d6b997), which carries:

- tinyhumansai#68 — typed `MemoryError` variants, read retries, deep health probes,
  honest `min_score`.
- tinyhumansai#69/tinyhumansai#71 — keyed CRUD: reads stop enumerating the account.
- tinyhumansai#73 — every crate moved under `crates/`, which is why the four path
  dependencies and both `[patch]` entries are re-pointed here.
- tinyhumansai#74 — the wire vocabulary extracted into `tinymemory-bus`.
- tinyhumansai#76 — adapter correctness: the Supermemory re-store `PATCH` that dropped
  the required container tag, keyed delete, fresh-namespace recall, capped
  error bodies.
- tinyhumansai#77 — the embedded engine off the executor, and KV reads spelling keys the
  way writes do.

`rusqlite` moves to `=0.40.2` in both cargo worlds because that is the exact
version `tinymemory-core` now pins, and the bundled SQLite must be a single
linked copy.

Both lockfiles resolve under `--locked`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`Markdown Link Check` went red on this branch: `src/openhuman/memory/README.md`
links to `tinymemory/tree/main/core/src`, and upstream tinyhumansai#73 moved every crate
under `crates/`, so that path is a 404.

The README link is now pinned to the commit this branch vendors
(`1d6b997`) rather than to `main`, so it describes the code the repo actually
compiles and cannot rot the next time upstream moves a directory. Overlaps
tinyhumansai#5654, which pins the same line to the *previous* vendored commit; whichever
lands second should keep the SHA that matches the submodule.

The same rename left six links in `gitbooks/features/obsidian-wiki/scoring.md`
and one path in `AGENTS.md` pointing at directories that no longer exist. Those
are outside the link checker's globs, so nothing reported them. All seven
targets verified to resolve.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The `Rust Feature-Gate Smoke (gates off)` lane failed on this branch for both
reasons the ratchet can fail: the pin sheds three packages the limit had not
been lowered for, and it adds one crate name.

Measured, not derived. Same macOS host, both pins, `scripts/kernel-floor.sh
flows --json`: old pin 286/265/2, new pin 284/266/2. CI (Linux) reads 283/265/2
against the old 286/264/2 — the documented +1 name target skew, unchanged.

The added name is `tinymemory-bus`, and a raise needs a reason, so here it is.
tinymemory#74 moved the wire vocabulary out of `tinymemory-api` into a crate
beneath it, so anything linking the api now resolves the bus crate too. It
brings no new third-party code — serde, serde_json, chrono, sha2, uuid, anyhow
and thiserror are all already in this profile, and its own manifest forbids it
an async runtime, rusqlite, git2, reqwest or regex. It is also the crate a host
links when it talks to the loadable TinyMemory module instead of compiling the
engine, which is the direction this ratchet exists to protect.

The three shed packages are real departures: `hashbrown 0.16.1`, `toml 0.9.12`,
`toml_datetime 0.7.5` and `winnow 0.7.15` leave; `dirs 6.0.0` and
`tinymemory-bus 0.1.0` enter. Everything else in the diff is a version bump the
pin carries (rusqlite 0.40.0 -> 0.40.2 and its libsqlite3-sys/hashlink tail,
tinymemory 1.0.1 -> 1.1.0). Native builds unchanged at 2.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Review catch: the note said -3 packages while listing four departures and two
arrivals, which is -2. The arithmetic was right and the baseline was wrong.

Re-measured `scripts/kernel-floor.sh flows` on both sides of this branch, on one
host each, instead of trusting the recorded number:

  base 5cd5b3a   Linux 285/264   macOS 286/265
  this branch    Linux 283/265   macOS 284/266

So -2 packages and +1 name on both hosts, and the Linux figure matches what CI
measured for the limit (283/265/2). The 286 this note had been differencing
against comes from the 2026-08-19 entry, whose lockfile is name-for-name
identical to this branch's base -- it is the macOS package count paired with the
Linux name count, one package looser than a Linux run measures. Recorded that
next to the entry so the next delta is not taken against it.

The review suggested reconciling by listing an older `dirs` as a fifth
departure. It is not one: `dirs 5.0.1` is a direct dependency of `openhuman`
itself, so it cannot leave on any host, and `dirs 6.0.0` lands beside it. That
is exactly why the package count moves and the name count does not, which the
note now says outright rather than in passing.

Limit line unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The Feature-Gate Smoke lane failed on this branch at "Guard — the removal
simulator still agrees with cargo". The guard pins the simulator's measured name
count so a drift between `scripts/dep-sim.py` and cargo's own feature resolution
is caught immediately, and it was still asserting 264 — the count from before
this PR. The bump adds exactly one name, `tinymemory-bus`, so cargo now says 265
and the assert fired. The simulator is calibrated correctly; the expectation was
stale.

This number tracks the same `flows` profile as scripts/kernel-floor.limits and
moves for the same reasons, so it has to be updated in whichever PR moves the
floor. It was easy to miss because nothing links the two: the limits file is
data with a history, this is an inline literal in a workflow. Left a comment
saying so, including that it expects the CI host — macOS resolves 266 and a
local run of the same command will disagree by one.

Verified: `python3 scripts/dep-sim.py --cut-nothing --expect-names 266` passes
on this macOS host, and a `--target x86_64-unknown-linux-gnu` resolution of the
profile gives 265 names, which is what CI measures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Rust Core Coverage failed four bypass-allowlist guards. tinymemory#73 moved the
engine from `core/` to `crates/tinymemory-core/`, and every allowlisted path
plus the scanner's own root still named the old location.

The scanner root is the part worth reading. `collect_rs_files` returns quietly
when `read_dir` fails, so pointing it at a directory that no longer exists did
not error -- it scanned openhuman's `src` alone and found none of the vendored
bypasses. That is the precise failure its own comment warns about ("would read
as `the bypasses were cleaned up` rather than `they moved out of view`"), and
the only reason it surfaced is that three of these tests assert the scan still
finds what the allowlist claims. A quieter guard would have gone green on a
half-blind scan and reported the bypasses as fixed.

So this does two things:

  - repoints the 12 ALLOWED entries and the scanner root at
    `vendor/tinymemory/crates/tinymemory-core/src`, verified file by file --
    all seven files exist there, and `.profile_store(` (the needle that matched
    nothing) has 16 live hits again;
  - asserts the vendored core directory exists before scanning it, so the next
    move fails with the path in the message instead of silently emptying half
    the tally.

Also corrects one line in the spec doc that named
`core/src/tinycortex/sync.rs`. That path does not exist at this pin and did not
exist at the previous one either -- it has been wrong since 8026897, and a
blanket path rewrite would have carried it forward as a differently-wrong path.
The file it describes is `core/src/engine/sync.rs`: inline `#[cfg(test)]` at
:752, tempdir workspaces calling `MemoryClient::from_workspace_dir`, which is
what the sentence claims and is already allowlisted twice.

Verified locally: all 6 tests in the module pass, `cargo fmt --check` clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>